In recent years, transmitters and receivers that have functions including streaming for transmitting and receiving images, sound, and content through communications networks are becoming popular on the market.
A conventional content transmitter is described next. FIG. 7 shows a structure of the conventional content transmitter. FIG. 10 shows a transition of a packet structure in conventional content transmitters and content receivers. FIG. 11 shows the conventional packet structure.
Video encoder 51 in FIG. 7 encodes video signals using a predetermined compression format, and outputs encoded signals to the next step. FIG. 7 shows the case of using the MPEG2 format. The output from video encoder 51 is composed of the MPEG2 transport stream packet (MPEG2-TSP).
System clock generator 54 generates a 27-MHz clock signal. Video encoder 51 uses this 27-MHz clock as a system clock for encoding video signals.
Audio encoder 52 encodes audio signals using the same compression format as video encoder 51, and outputs MPEG2-TSP signals to the next step. Data encoder 53 encodes data broadcasting and EPG data using the same compression format as video encoder 51, and outputs MPEG2-TSP signals to the next step.
Stream multiplexer 55 multiplexes the above three types of MPEG2-TSP signals on a time base. Stream multiplexer 55 also generates a PCR signal that reproduces the system clock on the receiving side by periodically using the count of the system clock at a cycle of about 50 ms. This stream multiplexer 55 further multiplexes the above multiplexed signals after encoding PCR signals to MPEG2-TSP, and outputs an MPEG2 transport stream (MPEG2-TS) signals to the next step (this output signal is S11 in FIG. 10).
FIG. 10 shows a transition of packet multiplexing on the time base. In FIG. 10, the abscissa is time. Any stationary delay in each processing is ignored, and thus are not indicated in FIG. 10. VIDEO1, VIDEO2, VIDEO3, AUDIO1, AUDIO2, and DATA1 in S11 are packets multiplexed by stream multiplexer 55. Moreover, VIDEO1, VIDEO2, and VIDEO3 in S11 are video-encoded MPEG2-TSPs. AUDIO1 and AUDIO2 in S11 are audio-encoded MPEG2-TSPs. DATA1 in S11 is data-encoded MPEG2-TSP. The PCR signal is a known fact in the MPEG2 system, and thus its description is omitted here.
Scrambler 56 encrypts MPEG2-TS using a predetermined encryption method, and outputs an encrypted signal. An example of the MULTI2 method is shown in the description.
RTP packetizer 58 encapsulates one or more individual MPEG2-TSPs. RTP packetizer 58 has a counter which counts the bus clock reproduced based on reference time information provided to transmitter receiver 61 from a communications network. Transmitter receiver 61 is described later. RTP packetizer 58 then adds a header containing a time stamp which is the count and information for identifying that encapsulated information is MPEG2-TSP to the output signal. This output signal is S12 in FIG. 10. RTP of S12 is the header. The time stamp is used for correcting jitter using the bus clock when a packet arrives at the receiving side.
UDP/IP packetizer 59 stores each RTP packet in an IP datagram for transmitting each RTP packet over the IP communications network. UDP-IP packetizer 59 then adds an IP packet header to each of the stored RTP packets, and outputs them as IP packets. This output signal is S13 in FIG. 10. The IP of S13 is a header such as the IP header in the communications protocol. The IP packet header is a known fact in Internet protocol, and thus its description is omitted here.
Ethernet packetizer 60 stores the IP packet in the Ethernet data region, adds an Ethernet packet header and checksum, and then outputs it as the Ethernet packet. The Ethernet packet header and checksum are known facts in Internet protocol, and thus their description is omitted here.
Transmitter receiver 61 transmits the Ethernet packet to the Internet network, and receives the aforementioned reference time information.
Next, the structure of the transmission packet mentioned above is described. FIG. 11 shows the structure of a conventional packet. In FIG. 11, ten MPEG2-TSPs are encapsulated, and an 8-byte header containing information for identifying MPEG2-TSP and a time stamp to be used at the packet arrival is added to create a 1892-byte RTP packet. Then, an 8-byte UDP packet header is added to this RTP packet to create a 1900-byte UDP packet. Next, a 24-byte IP packet header is added to the UDP packet to create a 1924-byte IP packet. Finally, a 14-byte Ethernet header and 4-byte checksum are added to this IP packet to create a 1942 Ethernet packet.
In the communications network, MTU, the maximum transmission unit, is often limited. Accordingly, on the communications network, the packet is split when the size of the packet data to be transmitted exceeds MTU. This type of processing is called fragmentation in the Internet field.
In the prior art, MTU on the Ethernet communications network is 1500 bytes. Fragmentation on the communications network is not preventable because the data size of the data region in Ethernet packets exceeds MTU. Therefore, a packet which has lost its header information exists in some cases, but packet loss or jitter is difficult to compensate for after fragmentation at the receiving side.
Next, a conventional receiver is described. FIG. 8 shows a conventional configuration of a content receiver. FIG. 9 is a flowchart illustrating the operation of receiving and decoding a packet.
Receiver 71 receives an Ethernet packet from a communications network such as the Internet, and outputs the packet to the next step. FIG. 11 shows this Ethernet packet. Ethernet packet processor 72 executes Ethernet protocol processing on the Ethernet packet given to Ethernet packet processor 72, and outputs an UDP/IP packet to the next step. STEP 91 in FIG. 9 shows this processing, and S14 in FIG. 10 shows the output signal.
S14 in FIG. 10 shows that jitter and packet loss has occurred in a received UDP/IP packet as a result of transmission and receiving of the received UDP/IP packet via the Internet. In other words, a delay greater than a stationary delay has occurred in a packet containing VIDEO1 and DATA1. A delay smaller than a stationary delay has occurred in a packet containing VIDEO3 and AUDIO2.
Next, jitter and packet loss on the Internet are described with reference to FIG. 10. A stationary delay exists between the transmitting and receiving sides on the Internet. Ideally, all packets are transmitted with this stationary delay. In this case, no jitter or packet loss occurs. However, in the Internet in practice, jitter or packet loss occurs due to packets being allocated different routes, deletion of the packet in the gateway because of the inability to transmit the packet within a packet valid time, re-transmission of the packet, and so on. The stationary delay is intentionally not indicated in S14 to help understanding of jitter on a limited space. More specifically, a delay greater than the stationary delay occurs in the packet containing VIDEO1 and DATA1, and thus S14 is more delayed (later) than S13 in the indication. Delay of the packet containing VIDEO3 and AUDIO2 is smaller than the stationary delay, and thus this packet is more advanced (faster) than S13 in the indication.
A packet containing only VIDEO2 and AUDIO1 is lost. UDP/IP packet processor 73 shown in FIG. 8 executes UDP/IP protocol processing on the UDP/IP packet, and outputs RTP packet. STEP 2 in FIG. 9 shows this processing. S15 in FIG. 10 shows this output signal.
The Ethernet and UDP/IP protocol processing mentioned above are a known fact in Internet protocol, and thus their description is omitted here.
These communications protocols contain, in their header, information on how to process data protocols. Each protocol processing method is standardized, and the content receiver is likely to possess the applicable processing method in advance. Accordingly, the content receiver can process the data protocol after deleting the header by analyzing information on the protocol in the header.
RTP packet processor 79 obtains the header of each RTP packet from each RTP packet shown in FIG. 11. RTP packet processor 79 also obtains information on structure data included in the header. This information on data contents is information for identifying a format of data stored. Here, this information identifies that the data is aforementioned MPEG2-TSP.
RTP packet processor 79 also has a counter for counting a bus clock reproduced based on the reference time information in receiver 71. RTP packet processor 79 counts this bus clock, and outputs MPEG2-TSP to the next step (Step 93 in FIG. 9) after removing the header when a count matches the time stamp in the header. RTP packet processor 79 then confirms whether MPEG2-TSP is scrambled (Step 94 in FIG. 9). The MPEG2-TSP header has information on whether MPEG2-TSP is scrambled in an area outside of the scrambled area. Accordingly, descrambling is applicable after taking out MPEG2-TSP and confirming the information. A predetermined method is applicable by determining in advance which method to use at the receiving and transmitting sides, or confirming and recognizing table information received on the receiving side.
Descrambler 74 descrambles and outputs MPEG2-TSP in accordance with a method corresponding to the scrambling method determined at the transmitting side. Step 96 in FIG. 9 shows this process. S17 in FIG. 10 shows this output signal.
TS decoder 77 adjusts MPEG2-TSP to a form to which AV decoder 78 can execute AV decoding (Step 97 in FIG. 9). AV decoder 78 executes AV decoding on data input to AV decoder 78, and outputs decoded data (Step 98 in FIG. 9). In STEP 93 in FIG. 9, if the bus clock count and the time stamp in the header do not match, TS decoder 77 verifies their difference (STEP 95 in FIG. 9). If the difference is within a range that can be compensated by a buffer in the reproduction controller (not illustrated), TS decoder 77 stands by an extended TS packet in this buffer. If the difference exceeds the range that can be compensated by the buffer, TS decoder 77 controls to dispose of the applicable TS packet (Step 96 in FIG. 9).
In the above configuration, however, a packet loss which has occurred on the communications network cannot be compensated in real time at the receiver, and thus a decoding error is generated when the packet loss occurs.
In addition, the RTP time stamp for jitter compensation is generated by counting the bus clock which is not related to encoding or decoding of the content. Moreover, the reference time information used for generating the bus clock has insufficient accuracy relative to the jitter accuracy required during decoding. Still more, this reference time information is affected by jitter on the communications network. These cause insufficient accuracy in jitter compensation during decoding on the receiving side in some cases, generating a decoding error.
Furthermore, since the data size of the data region in the communications packet exceeds the MTU in the communications network, fragmentation in the communications network is not preventable, resulting in loss of header information. This makes it difficult to compensate for, on the receiving side, the packet loss and jitter that occurs after fragmentation.